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A PROPRIETARY PROTOCOL FOR A SYSTEM 
CONTROLLER FOR CONTROLLING DEVICE CONTROLLERS ON 
A NETWORK HAVING AN OPEN COMMUNICATION PROTOCOL 



BACKGROUND 

4 The present invention generally relates to a communication protocol used 

5 in system controllers for network control systems, and more particularly to a protocol for 

6 a system controller for controlling a control system having a network with an open 

7 communication protocol. 

8 It is known in the control systems industry, especially the building control 

9 systems, to employ a control network to allow various system components to 

10 communicate with each other. Until recently, communication between the components 

11 in the network was handled through proprietary protocols developed by the control 

12 network developers/manufacturers. Increasingly, however, the control networks are 

13 now being implemented with open communication standards such as LonTalk® and 
u BACnet. These communication protocols permit system components that are produced 
is by different manufactures to communicate with each other, thus providing the network 

16 designers the flexibility to choose system components from various sources. 

17 Known control systems typically include one or more system controllers 

18 that are connected via a control network to device controllers that operatively control 

19 network devices. The system controllers typically transmit commands to the device 

20 controllers for operating the network devices, and also receive data from the device 

21 controllers regarding status and other information about the network devices that may 

22 be of interest to the system controller for making decisions. 

23 A problem associated with the known control system arrangements is that 

24 the communication between the system controller and the device controllers must be 

25 conducted via the open protocol of the system network. These protocols do not always 

26 have the capacity to provide the support necessary for implementing complex and 

27 increased functionalities required by some control systems, such as a 

28 Heating/Ventilation/Air Conditioning (HVAC) system, for example. The known control 

29 system arrangements also limit designers' creativity in solving problems or expanding 

30 the capabilities of the system controller, because the designers are confined to the 
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1 protocol of and the type of data provided by the network in place. Addition of new 

2 control applications to the control system is also complicated for the same reasons. 



3 SUMMARY OF THE INVENTION 

4 The present invention is directed a communication protocol which is 

5 employed in a system controller for controlling device controllers in a control system that 

6 is built around a network utilizing a network specific communication data format and 

7 protocol. The present proprietary protocol is adapted to be embedded in the network 

8 protocol and carry proprietary data between an application controller and various 
c 9 applications of the system controller. 

Eio BRIEF DESCRIPTION OF THE DRAWINGS 

In FIGURE 1 is a logical block diagram of a system controller that uses the 

tin present communication protocol; 

- L i3 FIG. 2 is block diagram of the system controller of FIG. 1 shown 

2 14 incorporated into a control network; 

2; 15 FIG. 3 is a logical block diagram illustrating the types of communication 

Ci6 protocols that may be employed in the control network; 

FIG. 4 is an illustration of the data fields associated with a single system 

18 point (SP) data format; 

19 FIG. 5 is a simplified illustration of various fields that are selectively 

20 provided in the system point protocol messages of the present invention; 

21 FIG. 6 is an illustration of a notification field in some of the present system 

22 point protocol messages; 

23 FIG. 7 is a system point protocol message format for a 

24 MSG_ID_SP_DISCOVER_PUID message; 

25 FIG. 8 is a system point protocol message format for a 

26 MSG_ID_SP_DISCOVER_NAME message; 

27 FIG. 9 is a system point protocol message format for a 

28 MSG_ID_SP_SUBSCRIBE_EL message; 

29 FIG. 10 is a system point protocol message format for a MSG_ID_SP_ 

30 UNSUBSCRIBE_EL message; 
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1 FIG. 11 is a system point protocol message format for a 

2 MSG_ID_SP_UNSUBSCRIBE_ALL_EL message; 

3 FIG. 12 is a system point protocol message format for a 

4 MSG_ID_SP_OVERRIDE_WRITE_SP message; 

5 FIG. 13 is a system point protocol message format for a 

6 MSG_ID_SP_RELEASE message; 

7 FIG. 14 is a system point protocol message format for a 

8 MSG_ID_SP_VAL_QUERY message; 

9 FIG. 15 is a system point protocol message format for a 

10 MSG_ID_SP_QUAL_QUERY message; 

u FIG. 16 is a system point protocol message format for a MSG_ID_SP_ 

L2 NODE_QUERY message; 

13 FIG. 17 is a system point protocol message format for a 

14 MSG_ID_SP_CANCEL_TRANSACTION message; 

15 FIG. 18 is a system point protocol message format for a 

16 MSG_ID_SP_SUBSCRIBE_EVENT message; 

17 FIG. 19 is a system point protocol message format for a MSG_ID_SP_ 
is UNSUBSCRIBE_EVENT message; 

19 FIG. 20 is a system point protocol message format for a MSG_ID_SP_ 

20 RESYNC message; 

21 FIG. 21 is a system point protocol message format for a 

22 MSG_ID_SP_EVENT_RPT message; 

23 FIG. 22 is a system point protocol message format for a 

24 MSG_ID_SP_DISCOVERED message; 

25 FIG. 23 is a system point protocol message format for a 

26 MSG_ID_SP_VAL_RPT message; 

27 FIG. 24 is an alternative system point protocol message format for the 

28 MSG_ID_SP_ VAL_RPT message of FIG. 23; 

29 FIG. 25 is a system point protocol message format for a 

30 MSG_ID_SP_QUAL_RPT message; 

31 FIG. 26 is an alternate system point protocol message format for the 

32 MSG_ID_SP_ QUAL_RPT message of FIG. 25; 
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1 FIG. 27 is a system point protocol message format for a 

2 MSGJD_SP_EVENT_RPT message; and, 

3 FIG. 28 is a system point protocol message format for a 

4 MSG_ID_APPLICATION_ERROR message. 

5 DETAILED DESCRIPTION 

6 Broadly stated, the present invention is directed to a proprietary 

7 communication protocol used in a system controller that includes an application 

8 controller and a plurality of applications for controlling a plurality of device controllers on 

9 a control network by using data relating to system points that correspond to data 

10 variables in the network. The protocol communicates a plurality of predefined 
n messages between the application controller and the applications for instructing the 

12 application controller to perform a function relating to a select system point, and for 

13 reporting to the applications in response to the instructions. The protocol includes a 

14 message identification field for identifying a select message from the plurality of 

15 messages, and a protocol identification field for identifying the select message as being 

16 transmitted via the proprietary communication protocol. 

17 In accordance with another aspect of the present invention, a proprietary 

18 communication protocol is used in a system controller that includes an application 

19 controller and a plurality of applications for controlling a plurality of device controllers on 

20 a control network by using data relating to system points that correspond to data 

21 variables in the network. The protocol communicates a plurality of predefined 

22 messages between the application controller and the applications for instructing the 

23 application controller to report events that occur in the applications and the device 

24 controllers, and for reporting to the applications in response to the instructions. The 

25 protocol includes a message identification field for identifying a select message from the 

26 plurality of messages, and a protocol identification field for identifying the select 

27 message as being transmitted via the proprietary communication protocol. 

28 Turning now to FIG. 1, a system controller in which the present 

29 communication protocol is used to transmit data is indicated generally at 100 and 

30 includes a plurality of applications 1 02, which are in communication with a network point 

31 record application (NPRA) 104. A system variable (SV) server 106 is connected 
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1 between the NPRA 1 04 and a control network 1 08 and serves as an interface between 

2 the NPRA 104 and the network dataflow. It should be noted that FIG. 1 is a logical data 

3 flow view of the system controller 1 00 and that the SV server 1 06 and the applications 

4 1 02 may reside at different locations along the network 1 08 from that of the NPRA 1 04. 

5 The NPRA 1 04 and the applications 1 02 may communicate directly, bypassing the SV 

6 server 1 06, or via the network through the SV server 1 06. 

7 As shown in FIG. 2, a control system 110 includes a plurality of device 

8 controllers that are network 1 08 compliant. They include application specific controllers 

9 (ASC) 1 1 2 (two shown) for controlling a number of physical devices 1 14, for example, a 
Bio variable air volume (VAV) box that controls a fan for blowing hot or cold air into an area. 
~ : n Also included are a number is programmable equipment controllers (PEC) 116 (one 
J?i2 shown), which also control physical devices 1 14 in the control system 110. In addition, 
sji3. the PECs 1 1 6 include features for enabling more sophisticated control processes, and 
Si4 generate data necessary for producing system reports. A workstation (WS) 1 1 8 allows 
L 15 a user of the control system 1 1 0 to input instructions to the device controllers 1 1 2, 1 1 6 
5i6 for controlling the physical network devices 1 14, and gain access to the system data 
T 17 necessary for making decisions regarding the operation of the control system 110. 

D 18 The WS 1 1 8, in the preferred embodiment, includes an internet interface 

19 119 which allows the WS to be interfaced with the internet 121 . A connection to the 

20 internet can be through an ethernet card or though a modem. Alternatively, an internet 

21 interface 1 19 can be provided in one of the PECs 1 16, in which case the connection 

22 mechanism to the internet 121 would be hard coded into the PEC instead of using an 

23 ethernet card. In this manner, the operation of the control system 1 1 0 can be controlled 

24 remotely through the internet 1 21 . 

25 The applications 102 may be a part of the workstation 118 used to 

26 subscribe for changes in the status of the network devices 114, for example. They 

27 might also be a part of the PEC 116, such as an alarm detector for detecting and 

28 reporting alarm conditions to an operator, or a totalization application for totalizing and 

29 calculating power used by the network devices 1 1 4, or for calculating the total ON time 

30 for a device such as a fan. The NPRA 104 provides a means of data collection, 

31 translation, reporting, and updating from data sources on the network 108. The SV 

32 servers 106 facilitate transmission of data or system variables (SVs) from the device 

33 controllers 112, 116 to the NPRA 104, and data from the NPRA to the device 
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1 controllers. The term system variables (SV) is defined to be values or data associated 

2 with the network devices 1 1 4 that are transmitted through the network via the network 

3 communication protocol, e.g., voltage from a sensor, a temperature reading, etc. 

4 As shown in FIG. 2, the system controller 1 00 is provided in the PEC 1 1 6 

5 or the workstation 1 1 8, but it may also be provided independently in a stand-alone unit. 

6 Each system controller 1 00 includes one NPRA 1 04, a plurality of applications 1 02 and 

7 one or more SV servers 1 06 which are incorporated into the device controllers 1 1 2, 1 1 6. 

8 Each ASC and PEC 112,116 represents a "node" in the network 1 08, which is a logical 

9 location of the SV server 1 06. While only one system controller 1 00 is shown in FIG. 2, 

10 it should be understood that more than one system controller may be provided in the 
% i control system 110, where each system controller would be responsible for operatively 
£12 communicating with its designated nodes. 

j;i3 Turning now to FIG. 3, communication between the device controllers 1 1 2, 

; /14 1 1 6 is through a protocol 1 20 that is specific to the network 1 08 on which the system 
S-15 controller 1 00 is connected, such as for example, LonTalk© in a LON network. Data or 
h. 16 system variables (SVs) that are transmitted between the SV servers 1 06 and the device 
£ n controllers 1 1 2, 1 1 6 are in the format defined by the network protocol 1 20. Between the 
18 SV servers 1 06 and the NPRA 1 04, the format of the data being transmitted is the same 
y[ 19 as at the network level. Accordingly, the mechanism of the protocol 1 20 of the network 

20 108 may be utilized in transmitting data, either through the local SV server 106 or 

21 directly between the NPRA 1 04 and the SV servers 1 06 in the other device controllers 

22 112, 116 in the network 108. 
A proprietary communication protocol 122 may also be used to transmit 

data between the NPRA 104 and the SV servers 106, so as to provide a layer of 
abstraction between the network 108 and the NPRA. In other words, the proprietary 
protocol 1 22 used between the SV servers 1 06 and the NPRA 1 04 would further isolate 
the system controller 100 from the network 108, so that the system controller is not 
bound to one particular control network. The proprietary protocol 1 22 at this level would 
also allow the system controller designers to implement additional capabilities in 
manipulating data or system variables. One example of the proprietary protocol 1 22 for 
implementing between the NPRA 104 and the SV servers 106 is described in detail in a 
commonly assigned patent application entitle PROPRIETARY PROTOCOL FOR 
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1 COMMUNICATING NETWORK VARIABLES ON A CONTROL NETWORK, filed 

2 simultaneously herewith. 

3 In accordance with the present invention, a "system point" (SP) is 

4 assigned for each system variable (SV) on the network 1 08 and other network data not 

5 associated with system variables. A system point might represent a room temperature 

6 or a room temperature setpoint measured or set by a thermostat (which would be a 

7 network device 114 shown in FIG. 2), for example. Each SP has associated dynamic 

8 and static information that are organized into various data fields. When the system 

9 variables (SV) from the SV server 106 are received, the NPRA 104 converts or maps 

10 the SVs into corresponding SPs. 

n In accordance with the present invention, data relating to the SPs are 

12 communicated between the NPRA 1 04 and the applications 1 02 via a system point (SP) 

13 protocol 1 24. The SP protocol is preferably embedded into the network protocol 1 20 of 

14 the network 108. In the LONTalk® protocol, for example, the SP protocol would be 

15 incorporated into the "explict messages" fields specifically designated for incorporation 

16 of proprietary communication messages. 

yj Turning now to FIG. 4, a single SP 1 26 is shown and includes a plurality of 

18 fields which describe the characteristics of the SP. The fields of the SP 126 are 

19 described in TABLE 1 below (the number next to the field name corresponds to the 

20 reference numerals of FIG. 4). 



Field Name 


Type 


S/D 


Description 


Name 126 


Array of 
36 U08's 


S 


User defined SP name. 


PUID 128 


U32 


s 


Unique ID number for the SP. 


VUID 130 


U32 


s 


Unique ID number for the SV associated with the 
SP. This field will be undefined if the SP is not 
associated with a SV. 


SVAddress 132 


U32 


s 


The logical address of the SV associated with 
the SP 


Over Enable 1 34 


U08 


s 


Indicates whether the SP can be overridden. 


SVT 136 


U16 


s 


The system variable type associated with the 
SP. 


Writable 138 


U08 


s 


This field defines if the SV corresponding to the 
SP can be written to. 


DefPollCycle 140 


R32 


s 


Default polling cycle for the SV associated with 
the SP. 
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Field Name 


Type 


s/d1 


Description 


PwrFailAct 142 


U08 


s 


This field is valid on writeable points only. 
Describes the action that the NPRA 104 will take 
when the NPRA is powered-on. 


Quality 144 


U16 


D 


This field provides the quality of the SP's value 
to indicate the condition of the SV associated 
with the SP. 


WrtPriority 146 


U08 


D 


The current write priority value of the SP. 


Ovrd Priority 148 


U08 


D 


The current override priority value of the SP. 


Element Number 
150 


U08 


S 


The identification number or index of the SP 
element. 


SPT 152 


U16 


S 


The type of the system point (engineering units). 


Def COV Limit 154 


R32 


S 


Default chanqe of value limit for the SP element. 


SP Numeric Value 
156 


Array of 
up to 32 
R32's 


D 


The current numeric value of an SP element in 
system point type (SPT) units. 


SP String Value 
158 


Array of 
32 U08's 


D 


The current string value of an SP element in SPT 
unit. 


User Defined 160 


User 
defined 


D/S 


Additional field for use in specific applications. 



TABLE 1 



2 The column named "Type" indicates the preferred number of bytes 

3 reserved for the corresponding fields of the SP. The first letter indicates whether the 

4 value is signed (S), unsigned (U) or a real number (R), and the following two numerals 

5 indicate the number of bits in the field. For example, the type "U08" represents an 

6 unsigned number having 8 bits (i.e., 0 to 255), and the type "S08" represents a signed 

7 number having 8 bits (i.e., -128 to +127). The S/D column indicates whether the field is 

8 static or dynamic. The static fields are not modified, while the dynamic fields may be 

9 modified. The SPs include one or more SP "elements," each of which is, in effect, an 

10 independent variable with an associated dynamic value. For example, one element of 
n the SP could contain a state, while another element could contain the time until that 

12 state occurs. 

13 Turning now to FIG. 5, and in accordance with the present invention, the 

14 system point (SP) protocol 124 includes a number of common fields, one or more of 

15 which are selectively incorporated into different messages. These fields include a 

16 protocol identification (ID) field 162 and a message ID field 164. In the preferred 
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1 embodiment, the protocol ID field 1 62 is set to PROT_ID_SP, which is an unsigned one 

2 byte value, i.e., a U08 value, for all SP protocol messages. The message ID field 1 64 

3 identifies the type of message that is sent from the clients 1 02 to the NPRA 1 04, or from 

4 the NPRA to the clients. 

5 An SP override/write command priority field 1 66 is preferably a one-byte 

6 field that holds the values that define the priority levels of the messages that are used to 

7 command writing or overriding of the SPs. The term "writing" is defined to mean 

8 updating of the SP value, and "override" is defined to mean updating of the existing SP 

9 values and also preventing other clients 1 02 from changing the overridden value. The 

10 priority levels prevent low priority clients 102 from overwriting or re-overriding the SP 
n values set by high priority NPRA clients. 

12 A transaction ID field 168, which is a four-byte field in the preferred 

13 embodiment, carries values representing the transaction ID of a message sent by the 

14 client 102 to the NPRA 104. The same transaction ID is then used in a response 

15 message or report from the NPRA 1 04 to the client 1 02. In this manner, the messages 

16 sent by the client 1 02 are readily identified with their corresponding responses from the 

17 NPRA 104. In the preferred embodiment, the client 102 uses a new and unique 

18 transaction ID each time it sends an SP protocol message. 

19 An event ID field 170 holds a value that identifies the type of event that is 

20 being subscribed for by the clients 1 02 from the NPRA 1 04. The event ID field 1 70 is 

21 also employed when the NPRA 1 04 reports on events that have occurred in the control 

22 system 1 1 0, for example, a node failure or a return from a node failure. A last message 

23 flag field 1 72 holds a value that indicates that a response message from the NPRA 1 04 

24 to the clients 102 is the last in the series of response messages, in the preferred 

25 embodiment, the NPRA 1 04 sets the last message flag field equal to "1" within the last 

26 message associated with a particular transaction. In all preceding messages the flag 

27 field 172 is set to "0". 

28 An SP element field 1 74 carries the values of the two different classes of 

29 the SP elements, which are string elements and numeric elements. The string elements 

30 are preferably limited to 31 characters in length, and therefore, will have up thirty-one 

31 U08 values stored in an array. The numeric element values in the preferred 

32 embodiment are expressed as an array of 1 to 31 32-bit floating values (i.e. R32's). 
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1 An element format field 1 76 indicates the format that the SP elements are 

2 to be conveyed. In the preferred embodiment, the messages designated as "format 0" 

3 convey only the value of the elements (such as for display on a Workstation 1 1 8 

4 application 102, while those designated as "format 1" are conveyed with units and 

5 formatting information so that the elements can be displayed on a portable (typically 

6 hand-held) device application 1 02. For numeric elements, these messages convey the 

7 system point type (SPT), formatting information (such as the element's units and the 

8 number of digits right of the decimal point), as well as the value of the numeric 

9 elements. For string elements, these messages convey the string length and the 

10 variable length character array that contains the contents of the string. 

n A notification field 178 is provided for setting flags that are used to 

12 individually enable, disable or indicate specific notifications relating to particular 

13 characteristics of the SPs. This is a single byte field that is bit-mapped as shown in FIG. 
w 6. For example, bit 0 of the field might be used for setting a "change of value" (COV) 

15 notification flag for changes in the value of a particular SP, and bit 1 of the field might be 

16 used for setting a "change of quality" (COQ) notification flag for changes in the quality of 
l? an SP, etc. While the notification field 178 is depicted in FIG. 6 as having four bits, 
is more or less bits may be designated for this field as necessary for notifying purposes. A 

19 date/time field 180 is also included in the SP protocol for conveying the date and the 

20 time values of an event that occurs in the control system 1 1 0. This field preferably holds 

21 a 64-bit floating (i.e., R64) value. 

22 The following predefined message types are sent from the clients 1 02 to 

23 the NPRA 104 and selectively include some of the fields shown in FIG. 5: 

24 MESSAGE TYPE MESSAGE ID 

25 Discover SP by PUID (unique system point ID) MSG_ID_SP_DISCOVER_PUID 



26 Discover SP by Name 

27 Subscribe Element 

28 Unsubscribe Element 

29 Unsubscribe All Elements 

30 Override/Write SP 

31 Release 

32 Value/Quality Query 

33 Quality Query 

34 Node Query 

35 Cancel Transaction 

36 Subscribe Event 

37 Unsubscribe Event 



MSG_ID_SP_DISCOVER_NAME 
MSG_ID_SP_SUBSCRIBE_EL 
MSG_ID_SP_UNSUBSCRIBE_EL 
MSG_ID_SP_UNSUBSCRIBE_ALL_EL 
MSG_ID_SP_OVERRIDE_WRITE_SP 
MSG_ID_SP_RELEASE 
MSG_ID_SP_VAL_QUERY 
MSG_ID_SP_QUAL_QUERY 
MSG_ID_SP_NODE_QUERY 
MSGJD_SP_CANCEL_TRANSACTION 
MSG_ID_SP_SUBSCRIBE_EVENT 
MSG_ID_SP_UNSUBSCRIBE_EVENT 
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1 Subscribe All COS MSG JD_SP_SUBSCRIBE_ALL_COS 

2 Unsubscribe All COS MSG JD_SPJJNSUBSCR!BE_ALL_COS 

3 Set Totalized Value MSG JD_SP_SET_TOTALIZED_VALUE 

4 Resync MSG_ID_SP_RESYNC 

5 Event Report MSG_ID_SP_EVENT_RPT 

6 The following predefined message types are sent from the NPRA 1 04 to the clients 1 02 

7 and selectively include some of the fields shown in FIG. 5: 

8 MESSAGE TYPE MESSAGE ID 

9 SP Discovered MSGJD_SP_DISCOVERED 

10 Value/Quality Report (format 0) MSG_ID_SP_VAL_RPT_0 
n Value/Quality Report (format 1) MSG_ID_SP_VAL_RPT_1 

12 Quality Report (format 0) MSG_ID_SP_QUAL_RPT_0 

13 Quality Report (format 1) MSG_ID_SP_QUAL_RPT 

14 Event Report MSG_1D_SP_EVENT_RPT 

15 Command NAK MSG_ID_APPLICATION_ERROR 

1 6 It should be noted that each message field is "serialized", i.e. its bytes are 
n stored in a predefined order. The preferable order is big endian, or the storing the most 

18 significant byte (MSB) of the field first. 

1 9 Each SP point in the NPRA 1 04 is assigned a unique identification (PUID) 

20 number. A MSG_ID_SP_DISCOVER_PUID message is broadcast from a client 1 02 to 

21 the NPRA 104 to discover if the NPRA has a specified SP within its database. The 

22 PUID number is stored in the PUID field 128 of each SP (best shown in FIG. 4). The 

23 NPRA 104 receiving this message responds by sending an 

24 "MSG_ID_SP_DISCOVERED" message (discussed below) containing the same 

25 TRANSACTION ID (as the MSG_lD_SP_DISCOVER_PUID message) to the client 1 02, 

26 if the SP with the specified PUID number is found in the SP database. The serialized 

27 format of the MSG_ID_SP_DISCOVER_PUID message in accordance with the SP 

28 protocol is shown in FIG. 7, including the protocol ID field 1 62, the message field 164, 

29 the transaction ID field 168 (shown in FIG. 5). In addition, the 

30 MSG_ID_SP_DISCOVER_PUlD message also includes a PUID field for identifying the 

31 PUID number of the SP stored in the database of the NPRA 104. 

32 A MSG_ID_SP_DISCOVER_NAME message is sent from the client 1 02 to 

33 the NPRA 1 04 to discover if a particular SP is stored within its database, as specified by 

34 the SP's unique text name. The NPRA 1 04 responds to this message by sending an 
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1 "MSG_ID_SP_DISCOVERED" message (discussed below) containing the same 

2 TRANSACTION ID (as the MSG_ID_SP_DISCOVER_PUID message) to the client 102, 

3 if the SP is found in the SP database that matches the unique text name. The serialized 

4 format of the MSG_ID_SP_DISCOVER_NAME message in accordance with the SP 

5 protocol is shown in FIG. 8, including the NAME field indicating the text name of the SP. 

6 Turning to FIG. 9, a MSG_ID_SP_Sl)BSCRIBE_EL message is sentfrom 

7 the clients 1 02 to the NPRA 1 04 to subscribe for changes in (value, state, quality, etc.) 

8 or periodic reporting of a specified element within selected SPs. This message may 

9 also be used to subscribe for changes in or periodic reporting of other characteristics of 

10 the SPs besides the SP elements. 

n In addition to the message fields described above in connection with the 

12 other SP protocol messages, the MSG_ID_SP_SUBSCRIBE_EL message includes an 

13 SP ELEMENT INDEX field that specifies the element within the SP for which the client 

14 102 wishes to subscribe. The SPs include up to 31 elements having values which 
is change independently. 

16 A NOTI FICATION field is provided for setting flags in the bit fields that are 

n used to individually enable specific notifications (for example, change of value (COV), 

is change of quality (COQ), change of state (COS), change of totalization (COT)) that the 

19 client is interested in subscribing. A SYNC/UNSYNC POLLING bit in the 

20 NOTIFICATION field is reserved for each type of notifications that are set. A "0" in this 

21 bit field instructs the NPRA 104 to poll for the specified notifications when the 

22 subscription (i.e., the MSG_ID_SP_SUBSCRIBE_EL message) is received, at the 

23 specified interval as indicated in a COV LIMIT/POLL RATE field set aside for this 

24 purpose. A "1 " in this bit instructs the NPRA 1 04 to poll at the specified interval set in 

25 the COV LIMIT/POLL RATE field, but starting only after a predetermined time, i.e., the 

26 start of polling is synchronized with a time boundary, as specified in a POLL SYNC 

27 TIME field . It should be understood that the POLL SYNC TIME field is only used in the 

28 message if the SYNC/UNSYNC POLLING bit is set to "1 ." Otherwise, this field is not 

29 used in the message. 

30 A "0" (ALL) in an ANY/ALL bit of the NOTIFICATION field indicates that all 

31 of the (COV, COQ, COS, COT) notifications enabled by the user in the message must 

32 be supported by the SP in the NPRA 1 04. If the SP does not support any one of the 
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1 selected notifications, then the message will not be accepted. A "1 " (ANY) indicates that 

2 any of the notifications (COV, COQ, COS, COT) enabled by the user and which the SP 

3 supports should be applied to the SP at the NPRA 1 04. The message will be accepted 

4 even if the SP does not support all the notifications enabled in the message. 

5 A POLLING/COV bit of the NOTIFICATION field determines whether the 

6 enabled notifications should be reported based on polling or when the value of the SP 

7 element changes. A USE_DEFAULT bit indicates (if the POLLING/COV bit is set to 

8 polling) whether the notification report should be based on the value change limit 

9 specified in the COV LIMIT/POLL RATE field of the message or the predefined default 

10 limit set in the database of the NPRA 1 04. It should be noted that the COV LIMIT/POLL 
l i RATE field contains either the value change limit or the desired polling rate. A REPORT 

12 FORMAT field is used to select a predetermined report format for receiving the reports 

13 from the NPRA 104. 

u Turning to FIG. 1 0, a MSG_ID_SP_UNSUBSCRIBE_EL message is sent 

15 from the client 102 to the NPRA 104 to cancel the subscription set by the 

16 MSG_ID_SUBSCRIBE_EL message. In addition to some of the fields discussed with 
i? respect to the MSG_ID_SP_SUBSCRIBE_EL, the MSG_ID_SP_UNSUBSCRIBE_EL 
is message indicates a DISABLE field for specifying the type of notifications (e.g., COV, 

19 COQ, COS, and/or COT notifications) to unsubscribe. 

20 Turning to FIG. 1 1 , a MSG_ID_SP_UNSUBSCRIBE_ALL_EL message is 

21 sent from the client 1 02 to the NPRA 1 04 to unsubscribe all notifications (COV, COP, 

22 COQ, COS, COT) on all SP elements on all SPs that the client 102 is currently 

23 subscribed to. This message is typically be sent at shutdown and start-up by the client 

24 1 02 (such as the workstation 1 1 8) to remove any remaining subscriptions. 

25 Turning to FIG. 12, a MSG_ID_SP_OVERRIDE_WRlTE_SP message is 

26 sent from the client 1 02 to the NPRA 1 04 to override or write new values to all elements 

27 within an SP. In addition to the fields described above in connection with the other SP 

28 protocol messages, this message includes a single-byte OVERRIDE/WRITE field 

29 including a bit (bit 7) for indicating the type of operation that is desired, i.e., whether 

30 override or write, and remaining bits (OVERRIDE/WRITE PRIORITY) indicating the 

31 priority of the message. The message will only be accepted by the NPRA 104 if the 

32 specified priority is greater than or equal to the current priority for the SP, as indicated in 
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1 fields 1 46, 1 48 of the SP (shown in FIG. 4). If the specified priority is below that of the 

2 current priority, a negative acknowledgement (NAK) is returned to the client 1 02 that 

3 sent the message. 

4 In addition to the common fields described above in connection with the 

5 other SP protocol messages, the MSG_ID_SP_OVERRIDE_WRITE_SP message 

6 includes an OPERATOR ID field which indicates the identity of a user who is 

7 responsible for sending the message. An SPF field indicates the total number of 

8 elements that are in the SP, and the ELEMENT VALUE fields hold the value of those 

9 elements to be overridden or written. In the preferred embodiment, the message only 

10 supports numeric element and not string elements. Element values are conveyed as a 
Sn 32-bit floating point number (i.e. an R32 number), and accordingly require 4 bytes for 
£12 each value, which are arranged from the most significant byte (MSB) to the least 
§113 significant byte (LSB), as shown in FIG 1 2. 

/;) i 4 Turning to FIG. 1 3, a MSG_ID_SP_RELEASE message is sent from the 

Wi5 client 1 02 to the NPRA 1 04 to release an SP from an override or write restriction so that 

p 16 other lower priority clients 1 02 are allowed to override or write to the SP. The effect of 

f . 17 the release is to clear the priority of the SP. It should be noted that any client 1 02 can 

^18 send this message, and not just the one that set the override or write of the SP. 

H 19 However, the message will only be accepted if the priority of the client 1 02 is greater 

20 than or equal to the current priority for the SP. Otherwise, a NAK is returned to the 

21 client 102. In addition to the common fields described above in connection with the 

22 other messages, this message includes a single byte OVERRIDE/WRITE field including 

23 a bit (bit 7) for identifying the type of release, i.e. , whether the release is for an override 

24 or a write. The remaining bits of of this field (OVERRIDE/WRITE PRIORITY) indicates 

25 the priority of the message so that the NPRA 104 is able to determine whether the 

26 message can be accepted. 

27 A MSG_ID_SP_XX_QUERY message is sent from the client 1 02 to the 

28 NPRA 1 04 to request a report on one or more SPs that currently have a particular data 

29 which is of interest to the client 102 sending the message. For example, a 

30 MSG_ID_SP_VAL_QUERY message, as depicted in in FIG. 14, is sent to request a 

31 report on an SP or on all the SPs that current have a write priority that is greater than or 

32 equal to the specified minimum write priority, and an override priority that is greater than 

33 or equal to the specified minimum override priority. Accordingly, in addition to 
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1 thecommon fields described above, the MSG_ID_SP_VAL_QUERY message includes 

2 MIN WRITE PRIORITY and MIN OVERRIDE PRIORITY fields. 

3 Turning to FIG. 15, a MSG_ID_SP_QUAL_QUERY message is sent from 

4 the client 1 02 to the NPRA 1 04 to request a report on one or more SPs that conform to 

5 the specified quality mask, which indicates whether the source of the data is operational. 

6 An example of an SP having a bad quality would be an SP that corresponds to a system 

7 variable (SV) which originated from a network device 1 1 4 or the device controllers 1 1 2, 

8 116 (shown in FIG. 2) that has experienced a failure. 

9 Turning to FIG. 16, a MSG_ID_SP_NODE_QUERY message is sent from 

10 the client 1 02 to the NPRA 1 04 to instruct the NPRA to immediately schedule a node for 
n interrogation to determine if that node has failed or is operational, rather than waiting for 

12 the scheduled next scan by the NPRA. In addition to the common fields described 

13 above in connection with the other messages, the MSG_ID_SP_NODE_QUERY 

14 message includes a SUBNET ID field and a NODE ID field which identify the logical 

15 network address of the node being queried. 

16 Turning to FIG. 1 7, the MSG_ID_SP_CANCEL_TRANSCTION message is 

17 sent from the client 102 to the NPRA 104 to cancel a previously sent 

18 MSG_ID_SP_XX_QUERY message. The transaction to be cancelled is specified by the 

19 TRANSACTION ID field. 

20 Turning to FIG. 1 8, the MSG_ID_SP_SUBSCRIBE_EVENT message is 

21 sent from the client 1 02 to the NPRA 1 04 to subscribe for event notifications. The term 

22 "event" is defined to mean general error conditions in the applications (clients) 102 in 

23 the control system 1 1 0. The message includes a MINIMUN EVENT SEVERTITY field 

24 that instructs the NPRA 1 04 to only report events that have a predefined severity level 

25 that is higher than the level indicated in this field. An APPLICATION ID field identifies 

26 the applications (clients) 1 02 for which the event notification is desired. 

27 A MSG_ID_SP_UNSUBSCRIBE_EVENT message is sentfrom the client 

28 1 02 to the NPRA 104 to unsubscribe for the event notifications described above. The 

29 SP protocol for this message is shown in FIG. 19. 

30 Turning to FIG. 20, a MSG_ID_SP_RESYNC message is sent from the 

31 client 1 02 to the NPRA 1 04 to instruct the NPRA to resynchronize or query all of the SV 

32 servers 1 06 operatively connected to the NPRA to determine which SVs are currently 

33 overridden, and then update the NPRA database with the results of these queries. 
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1 Turning to FIG. 21 , a MSG JD_SP_EVENT_RPT message is sent from 

2 the client 1 02 (or the NPRA 1 04 itself) to the NPRA 1 04 to report the occurrence of an 

3 event detected by the client, such as a node failure event or node return-from failure 

4 event detected by a NPRA. In addition to the common fields described above, the 

5 MSG_ID_SP_EVENT_RPT message includes an EVENT ID field indicating the type of 

6 predefined event that has occurred. The events have a predefined severity level, and 

7 those events that have severity level above the minimum level indicated in the EVENT 

8 SEVERITY field are reported to the NPRA 104. An EVENT TIME STAMP field is 

9 provided in the message to record the time of the event. The 

10 MSG_ID_SP_EVENT_RPT message further includes an ARG LENGTH field that 
Sn indicates the number of bytes that are in an ARGUMENT field, which provides the 
I12 detailed information about the event that is being reported. 

ffi 13 Turning to FIG. 22, a MSG_ID_SP_DISCOVERED message is sent from 

bji4 the NPRA 1 04 to a client 1 02 in response to a command from the client to discover SP 

fi5 by its point unique ID (PUID) number or its name (MSG_ID_SP_DISCOVER_PUID and 

M16 . MSG_ID_SP_DISCOVER_NAME messages shown in FIGS. 7 and 8) discussed 

SI n above, if the specified SP was found within the database of the NPRA. This message 

25 is includes, in addition to the common fields described above, a LAST MESSAGE field for 

Hi9 indicating whether this message is the last message associated with the transaction 

20 identified in the TRANSACTION ID field. 

21 Turning to FIG. 23, a MSG_1D_SP_VAL_RPT message is sent from the 

22 NPRA 1 04 to the clients 1 02 in response to requests from the clients for reports on the 

23 SPs for data of interest. In the preferred embodiment, this message is used to report 

24 the occurrence of a change of value (COV) and/or change of quality (COQ) for the 

25 specified SP and of a change of priority (COP) of the write priority and/or override 

26 priority for the specified SP. This message is used also in response to the 

27 MSG_ID_SP_SUBSCRIBE_EL message (shown in FIG. 9), for subscribing for an 

28 element of the SP, and in response to a request for a report on an SP that has a write 

29 priority that is greater than or equal to a specified minimum write priority and an override 

30 priority that is greater than or equal to the specified minimum override priority, i.e., the 

31 MSG_ID_SP_VAL_QUERY message (shown in FIG. 14) discussed above. 

32 As seen in FIG. 23, the MSG_ID_SP_VAL_RPT message includes, in 

33 addition to the common fields discussed above in connection with the other messages, 
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1 a NOTIFICATION field that has bit flags to indicate a change of value (COV) and a 

2 change of quality (COQ), if this message is sent as a COV/COQ notification report. If 

3 this message is sent in response to a query messages (the MSG_ID_SP_XX_QUERY 

4 messages shown in FIGS. 14-1 6), then the flags are cleared. A QUALITY field indicates 

5 the current quality level of the data source, which is needed if this report is in response 

6 to a query regarding quality, i.e., the MSG_ID_SP_QUAL_QUERY message (shown in 

7 FIG. 1 5). SP WRITE PRIORITY and the SP OVERRIDE PRIORITY fields convey the 

8 current write and override priority of the SP. The SPF field indicates the number of SP 

9 elements that are in the specified SP. 

10 It should be noted that the report format of the MSG_ID_SP_VAL_RPT 
n may be modified to provide the information specified by the requesting client 1 02. An 

12 example of an alternate format for reporting the MSG_ID_SP_VAL_RPT message is 

13 shown in FIG. 24, which in addition to the fields shown in FIG. 23, further includes a 

14 NAME field for providing the name of the specified SP, if this information is requested by 

15 the client 102. 

1 6 Turning to FIG. 25, a MSG_ID_SP_QUAL_RPT message is sent from the 

17 NPRA 1 04 to the client 1 02 in response to the MSG_ID_SP_QUAL_QUERY message 
is (shown in FIG. 15) or the MSG_ID_SP_SUBSCRIBE_EL message (shown in FIG. 9) 

19 with the COQ notification bit specified. In addition to the common fields described 

20 above in connection with the other messages, a QUALITY field indicates the predefined 

21 level of quality associated with the specified SP. The report format may be modified to 

22 provide the information specified by the requesting client 102. An example of an 

23 alternate format for reporting the MSG_ID_SP_QUAL_RPT message is shown in FIG. 

24 26, which in addition to the fields shown in FIG. 25, further includes a NAME field for 

25 providing the name of the specified SP, if this information is requested by the client 1 02. 

26 Turning to FIG. 27, a MSG_ID_SP_EVENT_RPT message is sent from 

27 the NPRA 1 04 to the client 1 02 to report the occurrence of the events specified by the 

28 client. In addition to the common fields described above in connection with the other 

29 messages, this message further includes ORIGINATOR SUBNET ID and ORIGINATOR 

30 NODE ID fields for identifying the logical network address of the node of the application 

31 (i.e., the client) 1 02 that has experienced the subscribed event. An APPLICATION ID 

32 FIELD identifies the application 102 that has detected the event. An EVENT ID field 

33 identifies the type of event that has occurred at the application 1 02, and an EVENT 
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1 SEVERITY field indicates the level of severity of the event, which is predetermined for 

2 each event. An EVENT TIME STAMP shows the time at which the event has occurred, 

3 and an ARG LENGTH field indicates the number of bytes (in the ARG field) that are 

4 used to provide detailed information (argument) regarding the event. 

5 Turning to FIG. 28, a MSG_ID_APPLICATION_ERROR message is sent 

6 from the NPRA 1 04 to the client 1 02 report that the NPRA was unable to execute the 

7 specified command from the client. A MODULE field indicates the software module 

8 where the error occurred, while an ERROR code field indicates the type of error that 

9 occurred (i.e., the reason why the NPRA 104 could not execute the command 

10 message). An ORIGINAL MESSAGE field contains the original command message that 
-li the NPRA 1 04 was unable to execute. 

From the foregoing description, it should be understood that an improved 

■13 protocol for a control network has been shown and described which has many desirable 

14 attributes and advantages. The SP protocol is advantageously employed in a system 

15 controller which is adapted to be integrated with any standard network control network. 

16 The present protocol serves to transmit data relating to "system points," which convey 
n information regarding desired system or user-defined variables in the network. The 
is present protocol is used to transmit system point data between the network point record 

19 application (NPRA) and the various applications in the network. 

20 While various embodiments of the present invention have been shown and 

21 described, it should be understood that other modifications, substitutions and 

22 alternatives are apparent to one of ordinary skill in the art. Such modifications, 

23 substitutions and alternatives can be made without departing from the spirit and scope 

24 of the invention, which should be determined from the appended claims. Various 

25 features of the invention are set forth in the appended claims 
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